1. Field
The present disclosure relates generally to client-server communications, and more specifically to switching between persistent and nonpersistent communications between client and server.
2. Background
The web originally used non-persistent methods of client-server communication in which a client would request web content, such as a webpage, and the server would return the content, and the connection between the client and server would close. The server was not able to initiate communication, although some implementations called for the client to periodically poll the server to see if the server had any unrequested data for the client. Early web servers were also known as ‘stateless’ since they did not store any knowledge regarding a client request or the content returned to the client in response to a request. In other words, once the web server served content, it no longer had any awareness of the client.
As webpages advanced they became more interactive and required lower latency. As a result, persistent communication protocols were developed that established a persistent two-way connection between client and server. These persistent connections were not torn down after the server transmitted data to the client, and also enabled the server to send data without a client request or polling. Instant messaging and VoIP are two examples of implementations where a client and server are both able to initiate data transmission over a persistently-open connection.
The WebSocket specification is one example of a persistent protocol and it defines an API that establishes “socket” connections between a web browser (the client) and a web server (the server). Sockets establish a persistent connection between client and server that stays open until either the client or server closes the connection. Sockets also enable either the client or server to initiate message transmission, thus removing the need for polling.
Despite the advantages of persistent connections, they still ‘time-out’ or terminate if a certain time period passes without any client or server communication. The WebSocket specification does not provide sufficient means to prevent timing out (also known as keep alive mechanisms). Software developers, therefore, often add their own keep-alive mechanisms to applications in order to keep a connection alive. For instance, many web applications periodically send keep-alive messages to the server in order to prevent the WebSocket from timing out.
Yet, these keep-alive mechanisms also interfere with power saving methods on many mobile devices. In particular, many mobile devices include power saving methods that transition the radio to low power states of operation (e.g., “Fast Dormancy”) after a period of radio inactivity. Developer keep-alive messages can be sent so frequently that they prevent these radio transitions and thus sap battery power faster than device manufacturers intended.
There is thus a need in the art for a way to engage in persistent communication that does not retard Fast Dormancy and other mobile device power saving mechanisms.